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PREFACE 


Purpose 

The  purpose  of  this  report  is  to  present  the  minutes  from  the 
Third  Workshop  on  Standards  for  the  Interoperability  of  Defense 
Simulations.  This  workshop  took  place  in  Orlando,  Florida  on 
August  7-8,  1990  and  was  hosted  by  the  Institute  for  Simulation  and 
Training  (ISTY,  a  part  of  the  Division  of  Sponsored  Research  for 
the  University  of  Central  Florida  (UCF) . 

This  cohtinuing  work  on  standards  is  sponsored  by  the  Defense 
Advanced^lSesearch  Projects  Agency  (DARPA)  and  is  administered  by 
the^Afmy  Project  Manager  for  Training  Devices  (PM  TRADE) . 

Background 

This  is  the  third  workshop  concerning  the  development  of 
technical  standards  for  networking  defense  simulations.  These 
standards  are  intended  to  meet  the  needs  of  large  scale  simulated 
engagement  systems  which  are  being  used  increasingly  to  support 
system  acquisition,  test  and  evaluation,  tactical  warfare 
simulation  and  training  in  DoD.  The  primary  goal  of  this  workshop 
was  to  recommend  revisions  to  the  proposed  Draft  Standard  for 
Protocol  Data  Units  in  Distributed  Interactive  Simulation  (DIS) 
published  in  June  1990  by  1ST.  Another  goal  of  the  workshop  was  to 
continue  work  towards  developing  standards  in  other  areas  of 
Distributed  Simulation. 


Workshop  Summary 

The  two  day  workshop  focused  on  three  major  topic  areas. 
These  are:  Communication  Protocols,  Terrain  Databases,  and  a  new 
area  called  Performance  Measures. 


Discussions  in  the  Communication  Protocols  Working  Group  were 
led  by  Joe  Brann,  IBM  and  Mike  McGaugh,  McDonnell  Douglas.  This 
group  concerned  itself  with  resolving  issues  related  to  the  Draft 
Standard.  Recommendations  were  made  for  incorporation  in  the 
revised  draft  standard  which  will  be  published  in  January  1991. 
One  subgroup,  the  Communications  Architecture  Subgroup,  met 
separately.  This  group  focused  on  issues  related  to  communications 
architecture.  In  particular,  this  group  sought  to  more  clearly 
define  the  services  that  a  DIS  requires  from  the  communication 
architecture  supporting  the  DIS  application.  This  group  was  led  by 
Steve  Blumenthal,  BBN  and  A1  Kerecman,  USACECOM. 

Discussion  in  the  Terrain  Database  Working  Group  was  led  by 
Mr.  Dexter  Fletcher,  IDA.  This  group  continued  its  work  with 
representation  and  interpretation  of  terrain  data. 
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A  new  working  group,  the  Performance  Measures  Working  Group, 
met  to  discuss  human  and  equipment  performance  measures.  This 
working  group  was  led  by  Dr.  Bruce  McDonald,  1ST.  This  group 
focused  on  operator  and  equipment  performance  measures  as  well  as 
required  level  of  fidelity. 

This  report  ha?  been  issued  in  three  volumes  Volume  I 
contains  the  minutes  for  the  plenary  session  and  a  list  o  i 
attendees.  Volume  II  contains  the  view-graphs  from  the  plenary 
sessions.  Volume  III  contains  the  view-graphs  used  in 
presentations  made  in  the  individual  working  groups. 
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SUMMARY  OF  ISSUES  FOR  DISCUSSION  BY  THE 
INTERFACE  &  TIME/MISSION  CRITICAL  SUBGROUPS 


The  following  is  a  list  of  questions  and  issues  resulting  from  the 
release  of  the  current  draft  standard.  Addressing  these  issues  is 
vital  to  formulating  a  final  draft  by  January. 

1.  Orientation 

a.  Should  Euler  angles  or  Quaternions  be  used  to  transmit 
orientation  of  an  entity? 

b.  Confirm  recommendation  that  angular  measure  be  in  BAMS: 

Unsigned  integers 
32  bit  BAM 

-  16  bit  BAM  for  articulated  parts 

2.  Dead  reckoning 

a.  How  should  various  dead  reckoning  algorithms  be 
specified?  (should  a  field  for  enumeration  values  be 
used,  should  entities  be  classified  according  to  the 
algorithm  used,  etc.) 

b.  Should  specific  algorithms  be  required  for  dead  reckoning 
or  should  each  simulator  be  free  to  use  its  own  algorithm 
(correlation  concerns)? 

c.  Should  default  update  rate  thresholds  be  established  in 
the  ACTIVATE  PDU? 

3.  Articulated  Parts 

a.  Should  articulated  parts  be  dead  reckoned?  If  so,  which 
ones?  What  kind  of  dead  reckoning  algorithm  should  be 
used? 

b.  How  many  degrees  of  freedom  are  required? 

c.  Develop  a  method  for  specifying  articulated  parts. 

-  Interim  solution 

-  Long  term  solution 

-  Sub-articulated  parts 

4.  Data  Representation 

a.  How  should  entity  rotation  rates  be  scaled  to  accommodate 
present  and  future  needs  (currently  a  32  bit  signed 
integer  is  specified  in  BAMs  per  sec.  It  is  argued  that 
this  provides,  at  most  1/2  rotations  per  sec)? 

b.  What  resolution  should  be  used  for  world  coordinates?  Is 


1/32  m  sufficient  (this  is  a  subgroup  recommendation;  the 
standard  specifies  cm)?  What  resolution  is  sufficient 
for: 

-  Engineering  systems 

-  Geosynchronous  orbits 

c.  Should  muzzle  flashes  be  represented  using  information  in 
the  FIRE  PDU? 

d.  How  much  information  about  a  platform  should  be  included 
in  the  appearance  PDU  and  how  much  should  be  considered 
“common  knowledge"? 

e.  Should  alignment  of  data  types  be  specified? 

f.  Is  there  a  need  to  provide  for  alternate  character  sets 
(currently  only  ASCII  characters  are  supported)? 

g.  Should  byte  (bit)  ordering  be  specified  (or  mentioned  at 
all)? 

h.  A  change  in  the  definition  of  the  32  bit  Entity  Type 
fields  is  recommended: 

Classification  -  4  bits  (0-3) 

Domain  -  4  bits  (4-7) 

This  change  is  recommended  to  make  it  more  readable  in 
hexadecimal.  Should  this  change  be  implemented? 

5.  Fixed  or  Floating  Point 

Should  the  use  of  floating  point  numbers  be  allowed?  If  so 
where  is  it  appropriate? 

6.  Dynamic  Thresholds 

Specifications  concerning  the  use  of  the  t1pdatf 
REQUEST/RESPONSE  PDUs  need  to  be  established. 

a.  Who  can  send  a  request? 

b.  How  are  multiple  requests  handled? 

-  Are  requests  queued? 

-  Tighter  thresholds  override  looser? 

c.  How  are  limitations  placed  on  the  request? 

d.  Should  a  request  time-out  and/or  should  there  be  a 
means  to  cancel  a  request? 

e.  Should  linear  thresholds  be  expressed  as  a  fixed 
length  or  a  percentage  of  the  size  of  an  entity? 
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When  and  how  are  default  thresholds  set? 


f . 


7 .  Weapons  and  Combat  Damage 

a.  Should  entities  that  have  been  affected  by  a  detonation 
be  specified  in  the  DETONATION  PDU?  If  the  entity  is 
specified,  should  the  location  of  the  detonation  be 
expressed  in  the  entity  coordinates  of  the  affected 
entity? 

b.  How  much  information  concerning  the  detonation  is  needed 
in  the  DETONATION  PDU?  (should  it  be  assumed  that 
entities  are  aware  of  the  force  of  certain  munitions  or 
should  the  force  be  specified?) 

c.  Develop  definitions  for  DIRECT  and  INDIRECT  fire. 

d.  Should  the  range  field  in  the  FIRE  PDU  be  represented  in 
meters  or  in  the  units  of  the  world  coordinate  system? 

e.  How  are  sky-shots  to  be  represented?  Should  the 
DETONATION  PDU  include  a  "result"  field  so  the  simulator 
knows  when  to  stop  modeling  the  trajectory  of  a  round? 

f.  How  are  bursts  of  machine  gun  fire  to  be  represented? 
How  are  tracers  to  be  represented? 

8.  Electronic  Tn+ er ' -tions 

a.  How  cucn  emitter  information  should  be  contained  within 
the  simulator  and  how  much  should  be  communicated  in  the 
PDUs? 

b.  A  description  of  what  kind  of  information  is  required  to 
be  contained  in  an  Emitter  PDU  is  needed  (this  would  also 
imply  the  types  of  information  that  is  required  to  be  in 
the  database)  .  What  will  serve  as  an  interim  solution  (A 
RADAR  PDU  is  recommended)?  V7hat  would  the  future  Emitter 
PDU  look  like? 

9.  Bit-encoded  Attributes 

Should  bit-encoded  attributes  be  used  in  the  Standard?  Should 

character  strings  be  used  as  an  alternative? 

10.  Query  Protocol 

Should  Query  PDUs  be  added  to  the  draft  standard?  Should  they 

be  part  of  a  future,  addition  to  the  current  draft? 

11.  Timestamps 
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Confirm  recommendation  that  timestamps  should  be  32  bit 
unsigned  integers,  LSB  representing  whether  the  timestamp  is 
absolute  or  relative. 

12.  Entity  Activation 

a.  How  are  missile  entities  activated/deactivated? 

b.  How  are  cultural  features  activated/deactivated  or 
modified? 

c.  Should  entities  be  further  classified  as  STATIC  and 
DYNAMIC  to  differentiate  the  activation  process  required 
to  introduce  them  to  the  simulation? 
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SUMMARY  OF  ISSUES  FOR  DISCUSSION  BY  THE 
COMMUNICATION  ARCHITECTURE  SUBGROUP 


The  following  is  a  list  of  questions  and  issues  resulting  from  the 
release  of  the  current  draft  standard.  Addressing  these  issues  is 
vital  to  formulating  a  final  draft  by  January. 

1.  Communication  Requirements 

Communication  requirements  of  the  DIS  application  should  be 
specified  (Network  management  functions  should  also  be 
specified).  Should  these  requirements  be  specified  in  the 
current  standard?  If  so,  how  should  they  be  stated? 

2.  PDU  size 

What  should  the  maximum  PDU  size  be? 

3.  Site,  Host,  Identification 

How  are  Identification  numbers  to  be  assigned?  Are  they 
permanently  assigned  or  assigned  at  the  start  of  each 
exercise?  Who  assigns  the  numbers? 


4.  TADIL-J / JTIDS/Link-16 

Should  these  models  be  adhered  to?  How  do  these  models  affect 
the  current  standard?  Future  standard  work? 

5.  Network  Traffic 

What  kinds  of  recommendation  can  be  made  to  reduce  the  number 
of  messages  that  need  to  be  issued  to  accomplish  the  goals  of 
DIS? 

6.  Priority  and  Security 

Fields  representing  the  priority  and  security  level  of  a  PDU 
are  going  to  be  added  to  the  PDU  header.  Does  the 
communications  architecture  group  have  any  recommendations 
concerning  how  this  should  be  accomplished? 
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SUMMARY  OF  ISSUES  FOR  DISCUSSION  BY  THE 
PERFORMANCE  MEASURES  WORKING  GROUP 

The  following  is  a  list  of  questions  and  issues  resulting  from  the 
release  of  the  current  draft  standard.  Addressing  these  issues  is 
vital  to  formulating  a  final  draft  by  January. 

1.  Entity  t  Event  Identifiers 

a.  When  should  Event  Identifiers  be  used? 

b.  How  should  Entity  Identifiers  be  assigned?  Who  assigns 
them?  Are  they  permanent  or  valid  only  for  the  duration 
of  the  current  exercise? 

c.  What  types  of  munitions  should  be  assigned  identification 
numbers?  How  should  this  be  accomplished? 

2.  Logistics  Support 

a.  How  are  simulated  repairs  to  be  represented?  How 
specific  do  the  repairs  need  to  be? 

b.  What  functions  should  be  defined  for  resupply?  (partial 
resupply,  messages  required,  etc.) 

c.  Should  DI  be  included  in  resupply? 

3 .  Environmental 

Training  and  equipment  evaluation  objectives  should  be  further 
defined  in  order  to  specify  sizes,  densities,  etc.  to  meet 
those  objectives. 

4.  Appearance  Information 

a.  What  kind  of  information  is  required  to  adequately 
describe  the  appearance  of: 

-  Aircraft 

-  Navy  ships 

-  Dismounted  Infantry 

b.  How  should  amphibious  vehicles  be  classified? 

c.  How  much  resolution  is  needed  for  articulated  parts? 


5.  Country  Information 

How  should  countries  be  specified?  Should  each  country  in  the 
world  be  included?  How  should  factions  within  a  country  be 
specified? 
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QUESTIONS  FOR  PERFORMANCE  MEASURES  GROUP 


OPERATOR  PERFORMANCE  MEASURES 

What  does  an  instructor  or  evaluator  need  to  know  to  evaluate 
operator/team  performance  at  the  end  of  the  exercise? 

What  does  an  instructor  or  evaluator  need  to  know  to  properly  run 
an  exercise? 

What  commands  do  instructors  or  evaluators  need  to  set  up  and  run 
an  exercise? 


EQUIPMENT  PERFORMANCE  MEASURES 

What  does  an  evaluator  need  to  know  to  evaluate  equipment 
performance  at  the  end  of  the  exercise? 

What  does  an  evaluator  need  to  know  to  properly  run  an  exercise? 
What  commands  do  evaluators  need  to  set  up  and  run  an  exercise? 


FIDELITY  MEASURES 

What  should  dismounted  infantry,  Green  Berets,  SEALS  look  like? 

What  do  you  do  when  the  resolution  of  the  simulator  display  will 
not  allow  a  target  to  be  identified  and  engaged  in  the  simulator  at 
the  same  range  as  in  the  real  world? 

Articulated  parts: 

Which  articulated  parts  and  other  appearances  have  training  or 
equipment  evaluation  value  and  require  representation? 

Aircraft 

Fighter 

Attack 

Bomber 

Reconnaissance 

Tanker 

Miscellaneous 


& 


Ship 


Carrier 

Battleship 

Cruiser 

Destroyer 

Frigate 

Patrol 

Submarine 

Amphibious  Assault 
Support 
Miscellaneous 
Land  Vehicles 
Tank 
APC 

Support 

Artillery 

Miscellaneous 

How  far  should  the  above  articulated  parts  move  before  a  new 
appearance  PDU  is  issued? 

Would  dead  reckoning  work  for  articulated  parts?  Which  ones? 

What  unclassified  submarine  sounds  are  important  in  ASW? 

How  do  we  communicate  classified  sounds? 

Should  the  Emitter  PDU  be  issued  less  often  since  electronic 
sensors  do  not  represent  the  position  of  platforms  as  accurately  as 
direct  vision? 

Is  the  representation  of  tracers  important? 
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Should  missiles  be  depicted  visually  in  flight? 

Subsonic  missiles 
Mach  1 
Mach  2 
Mach  2+ 

Should  ballistic  weapons  be  depicted  visually  in  flight? 

What  additional  indications  should  be  depicted  for  a  TOW  or  Dragon 
launch? 

How  do  we  coordinate  the  depiction  of  a  rotating  antenna  between 
simulators? 
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SUMMARY  OF  ISSUES  FOR  DISCUSSION  BY  THE 
TERRAIN  DATABASES  WORKING  GROUP 


The  following  is  a  list  of  issues  presented  in  position  papers 
submitted  as  a  result  of  the  Second  Cor'srence  on  Standards  for  the 
Interoperability  of  Defense  Simulations.  Addressing  these  issues 
is  vital  to  developing  a  draft  standard  for  Distributed  Interactive 
Simulation. 

1.  What  kind  of  database  information  should  be  a  requirement  for 
DIS? 

-  Terrain 

-  Emitter 

-  Information  concerning  entities 

(what  lacks  in  the  database  needs  to  be  communicated  in  the 
PDUs) 

2 .  Terrain  Databases 

a.  How  are  Terrain  Database  identifiers  assigned?  Who 
assigns  them? 

b.  Should  information  concerning  dynamic  terrain  (cultural 
feature  entities)  be  included  in  the  terrain  data  base 
information? 

3.  Oceanographic  Information 

How  is  oceanographic  information  to  be  represented? 


4. 


Dynamic  Terrain 

Develop  a  PDU  to  communicate  changes  in  the  terrain. 
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Terrain  Databases 
Working  Group 


Mr.  Dexter  Fletcher 
(for  Mr.  George  Lukes) 
Chairman 


00V  1177 


STATUS:  Distributed  Simulation  Database  Interchange 


Eric  Lang 
Steve  Smyth 

BBN  Advanced  Simulation  Division 


•  Conceptual  Model  (Smyth) 

The  basis  for  describing  a  view  of  the  simulated  environment. 
The  elements  adopted  in  SDIS. 

•  Product  Status  (Lang) 

SIMNET  database  conversion  to  SDIS. 

Supporting  software. 

User  comments. 
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Database  Interchange  Progress 

In  Work 
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Advanced  Database  Concepts  RSD 
BBN  Systems  and  Technologies  Corporatioi 
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SDIS  50Km  Dataset.  Packages 
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SDIS  Application  Programmer's  Interface 


SDIS  Application  Shell 
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SDIS  Dataset  User  Comments 
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Solution:  Add  application  specific  attributes  to  simplexes. 
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Solution:  Improve  API  package  editing  routines. 


SDIS  Dataset  User  Comments 
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Solution:  Provide  SDIS  Dataset  Dictionary  with  Datasets. 


SDIS  Availability 
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M 


Formal  description  of 

•  primitive  data  elements, 

•  their  properties, 

•  relationships  between 

elements,  and 

•  operations  that 

create, 
destroy, 
combine,  and 
change  elements. 


Smyth-02 
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Basis  for 


a 


•  the  design  and 

implementation  of  data 
representations, 

•  algorithm  design  and 

analysis, 


•  languages  to  express 
structure  and 
operations,  and 


data  communications 
protocols  to  transport 
data. 


Smyth-03 

31 


•  Real-world  entities  are 

represented  as  discrete 
objects. 

•  Structure  and  behavior 

are  encapsulated. 

•  Semantic  structure  is 

represented  as  DAG. 

•  An  entity  may  be  part  of 

several  objects. 


Smyth-04 
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ITlfa©  aolf  M©co\cd 


•  geometry:  physical 

form 

•  ©rientation:  rotational 

relationship  of  form 
to  space 

•  location:  translational 

relationship  of  form 
to  space 

•  frame:  the  spatial 

context  of  the  form 


Smyth-06 
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El© 

m 

r£8BI61 

T 

mm 

m 

m 

•  terminal  nodes  in 

semantic  network  (DAG) 

•  highest  level  of  detail 

•  specialized  (Leopard  2) 

•  concrete  (3D) 

•  detailed  (1cm  resolution) 

•  components  (wheel) 

•  disaggregated  (tree) 


Smyth-07 
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•  links  between  objects  that 

indicate  the  direction  and 
nature  of  base  -  non-base 
object  relationships 

•  level  of  detail:  coarse->fine 

•  abstraction:  abstract->concrete 

•  generalization: 

general->specific 

•  composition:  whole->part 

•  aggregation:  singleton->group 


Smyth- 16 
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•  origin  or  interior  nodes  in 

semantic  network  (DAG) 

•  reduced  level  of  detail 

•  generalized  (vehicle) 

•  abstract  (center  of  mass) 

•  crude  (looks  ok  from  afar) 

•  composite  (helicopter) 

•  aggregated  (forest) 

Smyth-08 
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eometrv 


•  physical  form 

•  simplex  primitives 

(point,  straight  line 
segment  or  arc,  triangle, 
tetrahedron) 

•  generators  for  non-planar 

and  procedurally-defined 
forms 

•  Boolean  composition 


Smyth-09 
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©Mentation 
r ,  ■— — — 


•  rotational  relationship 

between  object's  own 
internal  reference  frame 
and  the  space  in  which 
it  is  embedded 

•  can  be  unknown  or 

indeterminate 


Smyth- 10 
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[Location 

•  Points  (O-simplices)  and 

locations  are  not  the  same. 

•  Location  is  an  attribute  of  a 

point. 

•  Location  may  be  uncertain  or 

unknown. 

•  Location  may  be  specified  in 

many  ways:  Cartesian 
coordinates,  polar 
coordinates,  parametric 
coordinates,  or  a  locus 
of  points,  for  example. 


Smyth-1 1 
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[Frame  of  Reference 

•  spatial  context  for 

orientation,  location,  and 
other  spatial  relationships 

•  organized  in  graphs, 

usually  a  DAG  or  tree 

•  only  forms  with  connected 

frames  have  spatial 
relationships, 

•  frame  may  be  free: 

"imagine  a  table..." 

•  frame  may  be  of  maximum 

scope 

Smyth-12 
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•  Prototypes  define  geometry 

that  can  be  inherited  by 
an  unlimted  number  of 
instances. 

•  Prototypes  have  a  "null" 

reference  frame,  the 
"free  frame." 

•  The  binding  of  a  prototype 

with  a  frame  produces 
an  instance. 

•  Materialization  copies 

geometry  inherited  by  an 
instance  from  a  prototype 
and  creates  a  new  first 
class  object. 

Smyth-13 
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•  time-dependent  attributes: 

"effective  time"  ('last 
week  they  took  down 
the  fence  and  dug  a 
ditch  in  its  place’). 

•  state  of  knowledge  changes 

with  time:  "valid  time"  or 
"data  time"  ('last  week  we 
found  out  that  that  linear 
feature  in  the  aerial  photo¬ 
graph  was  really  a  ditch, 
not  a  fence  as  we  previously 
thought’) 


Smyth-1 4 


•  attribute  uncertainty  ('is 
that  fence  1m  high  or  10m?') 


•  object  class  uncertainty  ('is 

that  linear  feature  a  fence 
or  a  ditch?') 

•  many  times  alternate 

plausible  versions  of 
reality  must  coexist  in  a 
computer  representation 

•  data  quality  and  lineage 

attributes  may  be  used 
to  determine  the  reliability 
or  usability  of  a 
particular  "thread  of  reality." 

Smyth- 15 


===== . =  =====  ========  ==  = 

The  base  representation 
always  represents  a 
possible  configuration 
for  the  modeled  environment. 

A  connected  path  through 
objects  such  that  no  two 
of  the  objects  is  connected  by 
a  path  in  the  semantic 
network  and  for  which  there 
is  a  path  to  every  object  in 
the  base  representation 
also  represents  a  possible 
configuration  of  the  modeled 
environment  (a  "thread  of 
reality") . 

Smyth-1 7 
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computing  implicit  spatial 
relations 

spatial  indexing 

representation  of  raster  and 
vector  data 

encoding  the  golf  model 


Smyth- 18 
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•  geometry 

•  orientation 

•  location 

•  frame 

•  golf  supports  a  rich  model  of 

an  objectized  world 

•  multiple  simultaneous 

representations 

•  adjustable  granularity 

of  representation 

•  base  representation  has  been 

implemented  for  real 
applications^,,. 
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ITD  Decoding  System 


Stephen  Ford 


Digital  Mapping  Laboratory 
School  of  Computer  Science 
Carnegie  Mellon  University 


6  August  1990 
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Digital  Mapping  Laboratory  -  MAPS 


Research  areas  include  feature  extraction,  scene 
analysis  and  spatial  database  systems  for  digital 
mapping  applications 

MAPS  members: 

Research  Leader 

Dave  McKeown 

Research  Staff  and  Programmers 

Wilson  Harvey 

Matt  Diamond 

Federic  Perlant 

Jean-Christophe  Dhellemmes 

Jeff  Shufelt 

Emily  Burke 

Michael  Polis 

Stephen  Ford 

Felice  Goldgraben 


Carnegie  Mellon  University:  SIDS 
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ITD  Decoding  System 


Series  of  Programs  and  Shell  Scripts  to  Decode 
ITD  Files 

•  Outputs  ITD  Thematic  Files  to  Text  Files 

Feald:  2 
FeaType :  L 
Code:  IP 03 02 

Def :  Road,  loose/unpaved 
AttCount :  9 

Surface  type:  loose/unpaved 
Theme:  transportation 
Structure :  non-elevated 
Weather  type :  all  weather 
Travelwav:  non-divided 
Existence:  definite 
Accuracy :  accurate 
Slope  gradient :  3  % 

Width:  55  dm 
SegCount :  1 
List :  1  F 

•  Runs  on  DEC  or  SUN  Platform  under 
UNIX  Operating  System 


Carnegie  Mellon  University:  SIDS 
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Fort  Hood  ITD 


TRANSPORTATION 


Carnegie  Mellon  University:  SIDS 
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Fort  Hood  ITD 
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ITD  Decoding  System 


Available  for  Distribution 
Contacts 

*  Dave  McKeown 
Phone:  (412)268-2626 
E-mail:  dmm@maps.cs.cmu.edu 

*  Jean-Christophe  Dhellemmes 
Phone:  (412)268-8801 
E-mail:  jcd@maps.cs.cmu.edu 

*  Stephen  Ford 
Phone:  (412)268-3884 
E-mail:  sford@maps.cs.cmu.edu 
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Carnegie  Mellon  University:  SIDS 


Dynamic  Terrain 

-  Some  Thought  Experiments  - 

Michael  Moshell 
IST's  Visual  Systems  Laboratory 
8  August  1990 


CONTENTS 

Morning:  An  Invitation  to  Consider  Dynamic  Terrain 


1)  Virtual  Reality  versus  Tactical  Dynamic  Terrain 

2)  On  the  Feasibility  of  TDT 

3)  Four  TDT  Features 

•  Earthworks 

•  Cratering 

•  Track  Marks 

•  Hydrology 

4)  Networking  and  Database  Issues  for  TDT 


Afternoon:  A  Straw-Man  Architecture  for  TDT 

1)  A  Scenario 

2)  Checklist  of  Features  and  Activities 

3)  Database  Strategy 

•  Special  (Redundant)  DT  Database 

•  Hasty  and  Careful  (Bi-modal)  Updating 

4)  Computational  Elements 

•  Engineering  Workstation 

•  DT  Processor 

•  IG  and  Simulator 

5)  Communications  Protocol 

VSLB90.13-1 
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Virtual  Reality  vs.  Tactical  Dynamic  Terrain 


Virtual  Reality:  the  "buzz  word"  of  1990 

•  Head  Mounted  Stereo  Displays 

•  DataGlove™ 

•  Interactive  Physical  Simulation 

•  Shared  (Networked)  Graphical  Space 

VR  Research  at  IST's  Visual  Systems  Laboratory: 

•  Head  Tracking  Display  for  SIMNET 

•  Physical  Modeling  with  Constraints 

•  Object  Oriented  Modeling  &  Simulation 

•  Object  Oriented  Databases 

•  Virtual  Reality  Testbed 

BUT- 

Most  of  this  work  is  "6.1"  style  -  5  to  10  year  payoff. 

*  '  . .  —  -i 

Could  we  build  a  low  cost  networked  Dynamic 
Terrain  simulator  system  with  1990  technology? 

- 


That  is  the  question  we  will  address  today. 
We  call  this  "thought  experiment"  - 
Tactical  Dynamic  Terrain 
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Feasibility  of  Tactical  Dynamic  Terrain 


•  SIMNET  I:  300  polys  for  terrain,  400  culture,  300  models 

•  20  degree  FOV  x  3.5  km  = 

8.9  load  modules  (LM)  x  (<32  polys)  = 
up  to  285  polygons  in  view. 


Local  Area  = 
16  x  16  LM 


One  LM=.5km2 
<32  polygons 


Let’s  imagine  SIMNET  II  - 

•  600  polys  for  terrain  (300  static,  300  DT) 


Now,  HOW  MANY 

•  Emplacements 

•  Craters 

•  Track  marks 
Could  we  reliably  display? 
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Feasibility  of  Tactical  Dynamic  Terrain 


Emplacements 


•  Cheap:  9  polys 

•  Nice:  25  polys 


VSLB90 


Feasibility  of  Tactical  Dynamic  Terrain 


Track  Marks 

Case  1:  Straight  line  travel 

=  Two  polys  per  flat  surface. 


Each  LM  traversed  would  generate 
8  to  24  new  polys,  for  track  marks. 


Case  2:  One  maneuver  every  5  tank  lengths  (40m) 

=  (about)  12-15  maneuvers  per  0.5  km  (one  LM) 
of  which  about  half  would  cross  poly  bounds, 

r 

=  18  to  22  (*2)  =  36  to  44  polygons  per  LM 
traversed.  ' - - - 
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Feasibility  of  Tactical  Dynamic  Terrain 


Maximum  Feature  Densities  with  600  polygons  for  Terrain 
(300  for  Dynamic  Terrain): 


Polys  per 
Feature 

Max.  Nr. 
in  FOV 

Safe 
Density 
per  KM 

Emplacement  -  Cheap 

9 

33 

14 

Emplacement  -  Nice 

25 

12 

5 

Crater  -  Cheap 

13 

23 

10 

Crater  -  Nice 

48 

6 

3 

Track  Marks  -  Straight 

48/km 

6  KM 

3 

Track  Marks  -  Maneuvering 

80/km 

4  KM 

1.68 

_ . _ "  2o”degi 

1.27  km 

Area  =  2.23  sq  km 

3.5  km 


And 


•  If  the  IG  went  from  1000  to  2000  polygons  and  ALL 
the  gain  went  to  Dynamic  Terrain, 

-  then  we'd  be  using  1000  polygons  instead  of  300,  and  so 

•  These  maximum  numbers  increase  by  a  factor  of  3.3 

(or  you  could  "pick  any  three  items"). 
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Feasibility  of  Tactical  Dynamic  Terrain 


Levels  of  Detail: 


•  A  2m  high  crater  (or  earth  berm)  at  1  km  range  subtends 
0.11  degrees. 


•  SIMNET's  vertical  FOV  is  about  7.5  degrees,  128  lines 
-  so  one  pixel  is  0.058  degrees  high. 


7.5  degrees/128  lines 


•  Thus,  the  2m  berm  is  two  pixels  high  at  1  KM  range. 


•  If  one  simply  OMITS  all  DT  features  at  >  1  KM  range, 
this  reveals  at  most  2  pixels  of  whatever's  hiding  behind 
them. 


-  which  should  be  standing  in  a  hole,  too...  and  will 
automatically  be  "partially  buried"  by  the 
depth  buffer,  in  the  planar  poly  in  coarse  LOD. 
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Feasibility  of  Tactical  Dynamic  Terrain 


Maximum  Feature  Densities  with  600  polygons  for  Terrain 
(300  for  Dynamic  Terrain  AND  1  km  LOD  Control): 


Emplacement  -  Cheap 
Emplacement  -  Nice 
Crater  Cheap 
Crater  -  Nice 
Track  Marks  -  Straight 
Track  Marks  -  Maneuvering 


Polys  per 

F  eature 

Max.  Nr. 
in  FOV 

Safe 
Density 
per  KM 

9 

33 

183 

25 

12 

66 

13 

23 

126 

48 

6 

34 

48/km 

6  KM 

34 

80/km 

4  KM 

20.6 

,363  km  Area  =  .18sqkm 

•  You  can  STILL  "pick  any  three  items"  if  were  using  1000 
polygons  for  DT  features. 
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Four  Dynamic  Terrain  Features 


•  Earthworks 

(Emplacements,  tank  traps,  drainage,  fords) 

The  Need:  Hull  Defdade! 

The  key  problems:  variable  shape ,  lots  of  polys 


•  Craters 

(Bomb  and  Artillary  impact,  mines) 

The  Need:  Improved  fidelity 
The  key  problem:  LOTS  of  craters! 

•  Track  Marks 

(Armor  Tread  damage  to  soil  &  vegetation) 

The  Need:  Evidence  of  enemy  travel 

The  key  problem:  LOTS  of  polygons,  overlaid. 

•  Hydrology 

(Rain  accumulating  in  low  places,  forming  streams) 

The  Need:  Critical  effect  of  precip  on  trafficability 
The  key  problem:  Updating  the  whole  terrain  at  once . 
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Networking  and  Database  Issues  for  DT 

1)  A  Scenario 

—  A  story  incorporating  the  Four  Features  — 

2)  Checklist  of  Features  and  Activities 

—  What  computations,  communications? 

3)  Database  Strategy 

•  Special  (Redundant)  DT  Database 

•  Hasty  and  Careful  (Bi- modal)  Updating 

—  Show  SOMETHING  now;  get  it  right  later 

4)  Computational  Elements 

•  Engineering  Workstation 

•  DT  Processor 

•  Image  Generator/Simulator 

5)  Communications  Protocol 
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The  TDT  Scenario 


The  TDT  Scenario 


A  Refresher  on  SIMNET  Terminology 

Field  of  View  (FOV)  =  (various);  15  deg  x  3  km 


Local  Area  (LA)  = 

16  x  16  Load  Modules 


Load  Module  (LM)  = 
0.5  x  0.5  km  of  terrain 


•  Local  Area  Memory  (LAM)  =  RAM  memory 

for  storing  the  Local  Area  data. 

•  Platform  =  weapons  carrier  (tank,  APC,  man) 

•  Entity  =  simulated  active  element,  usually  a 

Platform 


My  terminology: 

•  Local  Area  Fringe  (LAF)  =  the  set  of  Load 
Modules  around  the  edge  of  the  Local  Area  -  i.e. 
"just  out  of  sight"  of  the  central  viewpoint. 
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The  TDT  Scenario 


A.  Blue  force  moves  eastward  (1) 

B.  Red  artillary  unit  (2)  bombards  bridge  (3),  craters  the 

road  (4);  retreats  to  northeast. 

C.  Blue  bulldozer  cuts  a  ford  across  the  stream  (5) 

D.  Blue  unit  arrives,  cannot  cross  bridge,  uses  ford. 

E.  Rain  falls,  muddies  the  scene.  Stream,  lake  rise. 
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A  Checklist  of  Features  and  Activities 


Computation: 

(1)  Red  artillary  computes  impact  locations 

(2)  "Someone"  decides  bridge  is  destroyed,  reshapes  it 

(3)  "Someone"  computes  new  microterrain  for  craters 

(4)  Trafficabilities  get  updated  so  tanks  can't  use  bridge 

(5)  Bulldozer's  action  simulated  while  cutting  the  ford 

(6)  Rainfall's  effects  are  computed 

(7)  Track  marks  are  laid  down  by  all  parties 

Communication: 

(1)  All  simulators  must  know  about  all  site  specific  terrain 

events  (craters,  digging  operations,  track  marks). 

(2)  Global  effects  (rainfall)  have  to  be  applied  to  the  whole 

database. 

(3)  Communication  must  be  timely  and  must  not  overload 

simulation  (entity)  communications. 


Now,  let's  propose  an  architecture  for  doing  all  this. 
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A  Straw  Man  Architecture 


•  New  Boxes  in  the  SIMNET  Diagram: 

Private  DT  Channel 


Engineer's 

DT  Processor 

DT  Database 

Workstation 

i 

$ 

i 

1 

Ethernet 


Simulator 

Simulator 

Simulator 

•  •  • 

Simulator 

•  Database  Strategy: 

A  Simulator  can  need  DT  information  in  2  ways: 

(1)  "Being  there"  (LA  overlaps  the  location  of  action) 

(2)  "Walking  up  on  it"  (LA  moves;  action  is  in  LA  fringe) 
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Database  Strategy 


(1)  "Being  There" 


•  ASAP:  simulators  show  a  temporary  "flat  poly"  to 
indicate  action. 


"manhole-cover"  for  a  crater  ...  ^ 

"work  in  progress"  polygon  for  ditch 


•  DT  processor  or  EWS  constructs  proper  form, 

installs  it  in  the  DT  database,  announces  avail¬ 
ability  of  an  updated  LM 

•  Simulator  notices  it's  in  LA,  requests  the  new  LM. 


•  DT  database  broadcasts  new  LM;  all  sims  copy. 


(2)  "Walking  up  on  it" 

•  Simulator  notices  those  LM's  in  the  LAF  which  are 
not  current,  requests  them  from  the  DT  database. 


•  DT  database  broadcasts  new  LM's;  all  sims  copy. 
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Database  Strategy 


•  The  Importance  of  all  simulators'  copying  each  upload: 

-  All  LM's  in  all  Databases  are  either  CURRENT  or 

at  most  ONE  UPDATE  OLD. 

•  The  magnitude  of  an  update:  usually  just  1/16  of  a  LM! 

-  Just  upload  the  "dirty  quads".  Cost? 

Crater  (good):  48  polys  x  4  vertices  x  3  nrs  =  576  numbers 
Emplacement  (cheap):  9  polys  x  4  v  x  3  nrs  =  108  numbers 

•  Uploads  can  be  batched  or  dispersed;  not  urgent. 

-DT  database  can  "spread  the  load  across  time", 
avoiding  saturation. 
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Computational  Elements 


•  Engineer's  Workstation 

-  SG  Iris  4D70GT  (seems  to  work  fine) 

-  Spline  based  interactive  earthworks  (human  operator) 

-  Polygon  relaxation  algorithm 

-  update  DT  database  when  'dozer  leaves  the  ditch 


•  DT  Processor 


-  Manages  the  automatic  stuff:  craters,  others'  tracks,  etc. 

-  Watches  net  traffic,  builds  appropriate  DT  structures 

-  often  (e.g.  craters)  just  invokes  templates  (additive!) 

-  probably  has  a  complete  (redundant)  DT  database 

(why  two?) 

-  Database  machine  processes  queries; 

-  DT  processor  modifies  terrain  additively 


•  The  Private  Channel 

-  High  bandwidth  (e.g.  shared  memory,  DMA) 

-  Possibly  not  necessary  for  the  'dozer,  because  of 

terrain  relaxation  prior  to  transmission. 
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Computational  Elements 


•  Image  Generators  and  Simulators 

(The  Crux  of  the  Matter ,  of  course) 

-  LM  Validity  Table 

-  Keeps  track  of  validity  of  all  LM's 

-  motion  of  the  LA  =>  fix  any  invalid  LM's  (query) 

-  continuous  netWatch;  pick  up  others’  fixes  into  DB 

-  Temporary  flat  features  in  LAM: 


-  manhole  covers,  working  'dozer  patches,  as 

needed  by  "reading  the  mail"  on  the  net. 

-  No  need  to  add  to  ownship  DB. 

-  tread  marks.  Add  to  ownship  DB  and  LAM. 

Meanwhile,  being  added  to  DT  Database  too. 
(BY  the  DT  database  processor 
on  basis  of  his  dead  reckoning  model) 

When  any  simulator  picks  up  a  dirty  LM,  it 
gets  the  latest  tread  information. 

Why  handle  tracks  differently?  Too  many! 


-  Double-buffer  the  whole  local  database!  (2  disk  drives) 
Drive  A  is  "read  only"  (queried  by  IG,  other  drive) 
Drive  B  is  "write  only"  (uploading  new  LM's) 

--  then  swap  'em. 
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Protocol 


DT-EVENT: 

emitted  by:  All  simulators  &  processors  causing 
DT-relevant  events.  E.g.  a  tank  fires  a  round. 

information  in  PDU: 

LM  affected. 

IG's  with  this  LM  in  LAM  must  put  up  a  temp. 
Other  IG's  just  mark  the  LM  "invalid-pending" 

Impact  location. 

DT-Event-Type  (crater,  earthwork,  etc.) 
Orientation  (earthwork's  long  axis) 

AVAILABLE-NE  W-LM : 

emitted  by:  DT  Database,  announcing  an  updated  LM 

information  in  PDU: 

LM  affected. 
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Protocol 


ASK-LM: 

emitted  by:  A  simulator  with  an  invalid  LM  in  its  LAM 
or  which  has  just  moved  across  an  invalid  LM. 

information  in  PDU: 

LM  id. 

NEW-LM: 

emitted  by:  DT  Database,  brc  adcasting  an  updated  LM 

NOTE:  This  is  the  PDU  whose  transmission  must 
be  minimized;  it  is  the  only  bulky  PDU. 

information  in  PDU: 

LM  affected. 

List  of  polys  to  be  deleted,  by  number 
List  of  polys  to  be  added,  with  attributes 
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The  Computation  Checklist  Revisited 


(1)  Red  artillary  computes  impact  locations 

—  and  broadcasts  them  via  an  (existing)  PDU 

(2)  "Someone"  decides  bridge  is  destroyed,  reshapes  it 

(3)  "Someone"  computes  new  microterrain  for  craters 

(4)  Trafficabilities  get  updated  so  tanks  can’t  use  bridge 

—  these  are  all  done  by  the  DT  Processor 

(5)  Bulldozer's  action  simulated  while  cutting  the  ford 

—  the  Engineer's  Workstation 

(6)  Rainfall's  effects  are  computed 

(7)  Track  marks  are  laid  down  by  all  parties 

—  The  DT  Database  does  these  functions 
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What's  Easy?  What’s  Hard? 


In  increasing  order  of  difficulty: 

Earthworks 

—  small  number  of  polygons;  infrequent 
Craters 

—  simple  to  execute,  but  could  have  thousands 
Track  marks 

—  everybody  makes  them,  all  the  time. 

—  Uploading  the  dirty  LM’s  may  be  overwhelming 
+  Ownship  responsibility  could  extend  to  DR  models 

Rainfall 

—  creates  puddles  all  over  the  database 

—  every  low  spot  in  terrain  is,  in  essence,  a  crater! 

Some  Hybrid  Ideas: 

•  Do  Earthworks  as  above;  leave  craters=manholes 
•  Your  turn! 
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Discussion  and  Recommendations _ 

A.  What  have  I  missed?  (Whole  issues?) 

B.  Is  my  "rank  ordering  of  difficulty"  right? 

C.  Queries:  a  bad  thing?  (Yesterday  it  seemed  so) 

—  rationale:  "need  to  know"  — >  offscreen  stuff  never 

crosses  the  net 

D.  The  above  approach  REQUIRES  all  simulators  to  be 
using  the  same  IG  or  at  least  polygonization  scheme.. 

I  claim  that  with  today's  technology,  no  other  DT  scheme  is 
feasible.  Correlation  will  just  be  too  hard  to  solve  in  realtime. 

> _ I _ _ — - 

Recommendations: 

«"  Standards"  imply  that  >1  organization  is  DOING  it  » 

«  Come  forward,  admit  you're  doing  it,  if  you  are!  » 
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PRESENTER:  KEVIN  BACKE 
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ITD  BRIEFING  OUTLINE 
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•  DTED  I  (Digital  Terrain  Elevation  Data)  SUPPLIED  WITH  ITD 


ITD  FORMAT 
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STUDY  POTENTIAL  OF  ITD  TO  SUPPORT 
GROUND  FORCES  SIMULATION  (P2851/RRDB) 


O 

5 

Q 

I 

p! 

UJ 

5 


Q 

K 

GO  CD 

>  s 

^  cc 
CD  _q 

Q  CD 

$ 

COQ 

~  O 
LO  CO 

°°3 
CM  c 
Q_  E 


LU  CD 

S" 


o 


co 


o 


h- 

3 


o 

co 

LU 

DC 


CO 
I — 

z 

LU 

LU 

DC 

3 

O 

LU 

DC 

LU 

CD 

< 

CD 

o 

I — 

CO 

• 


H 

< 


O 

LL 


95 


•AREA  COVERAGE  REQUIREMENTS 
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•  MOBILITY  MODEL  PRODUCES  SINGLE  POLYGON  DATA  FILE  OF 
SPEED  RANGES  OR  "GO”,  "SLOW",  "NO  GO"  AREAS 


RESOLUTION  ISSUE 
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►  ITD  IS  A  ROBUST  DIGITAL  TOPOGRAPHIC  DATABASE 
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►  FURTHER  INVESTIGATION:  HOW  CAN  ITD  DATA  VOLUME  BE 
REDUCED  WITHOUT  LOSING  VALUABLE  INFORMATION? 


Communications  Protocols 
Working  Group 


Ron  Hofer 
Chairman 


0096-1222 


Interface  &  Time/Mission 
Critical  Subgroup 


Mike  McGaugh 
Joe  Brann 
Chairmen 


0096-1223 


INTERFACE  WORKING  GROUP  SCSD 


Daytona  Beach 
Florida  32015 
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ARTICULATED  MAN  (BODY,  HEAD,  ARMS 
(UPPER,  FOREARM,  AND  HAND),  LEGS 
(THIGH,  CALF,  FOOT) 


J 


Communication 

Architecture 

Subgroup 


Steve  Blumenthal 
Chairman 


0091-1176 


COMMUNICATIONS  ARCHITECTURE  SUBGROUP  MEETING 
AUGUST  8.  1990 


I. 

II. 

III. 

IV. 

V. 


REVIEW 
1ST  UPDATE 

SINCGARS  VOICE  NETWORK  SIMULATOR 

BB&N  PRESENTATION 

ISSUES  FROM  POSITION  PAPERS 


Al  Kerecman 
Dr.  Henry  Williams 
Larry  Goldberg 
Steven  Blumenthal 


VI.  REQUIRED  NETWORK  SERVICES 

VII.  ARCHITECTURE 

-  Network  Management 

-  Simulation  Management 

-  Configuration  Management  &  Network  Support 

-  Security 

VIII.  CONFORMANCE  &  INTEROPERABILITY 

-  Procedures 

-  Test  Tools 

-  Network  Support 

IX.  PROGRAM  PRIORITIZATION  LIST 
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I.  DISTRIBUTED  SIMULATOR  ARCHITECTURE  [DSR] 
DEUELOPMENT 

Purpose:  to  replace  the  SIMNET  association  layer 
protocols  uiith  eelstlng  COTS  protocols  for  proof  of  OS  I 
profile  Implementation  concept. 

R.  Analyze  the  BBDN  SIMNET  Association  layer  Interface 
for  functions  which  can  be  provided  by  PSI. 

B.  Decouple  SIMNET  modules  uiblch  embrace  ether  than  OSI 
Layer  7  functions:  resulting  In  on  Interactive  Simulation 
Protocol  IlSPl  capable  of  being  coupled  to  OSI. 

C.  Submit  ISP  to  ANSI  for  constdeffltlea  as  on  OSI  Application 
Layer  Simulation  Standard. 

0.  Replace  etboraet  with  802.S 

E.  Interface  ISP  to  ISOOE  for  IptH  (purposes. 

Run  the  ISP  hppearance  petitnri  ever  ISOOE. 

F.  Compare  the  pen-multicast  IS#B!  performance  with  the 
BBDN  SIMNET bnple mentation. 

G.  Decouple  TCP/IP  from  ISOBE  ead  Replace  TCP/IP  with  HTP, 
UMTP/IP,  and  iPP  Multicast  IP;  test  the  performance 
characteristics  of  each  In  tbe  ISOOE  altered  profile; 
compare  perfermance  wlthiBfrN  SIMNET. 

H.  Implement  and  tune  one  sobstack  from  6  aboue  based 
upon  ANSI /OS I  coordination  and  acceptable  performance. 

I.  Couple  FDDI  into  simulator  platforms  and  run  comparison 
performance  tests  against  the  802.1  supported  units. 

J.  Provide  the  Distributed  Simulators  Profile  [DSCP]  to  PM 
TRADE  for  submission  to  JCS,  as  the  standard  OoD 
simulator  networking  profile. 

K.  Encourage  uendors  to  make  the  source  code  of  the  ISP 
reference  implementation  available  In  tbe  public  domain 
free  of  charge. 
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II.  INTERRCTIUE  SIMULATION  PROTOCOL  (ISP) 


Purpose:  To  produce  o  standard  application  layer 
protocol  for  distributed  simulators  networked  In  on  SSI 
environment. 


fl.  From  the  ISP  Standard  Development  effort,  (IR,  IB,  and 
1C),  document  the  resultant  ISP  and  distribute  it  as  the 
draft  application  layer  standard. 

B.  Provide  attendance  from  UCF  1ST  to  the  NIST  OSI 
Workshop.  Attend  three  parallel  sessions  on  a  regular 
basis  for  the  following  reasons: 

1.  Application  Layer  Sessions  -  to  promote,  discuss,  and 
defend  the  ISP  submission. 

2.  Transport  Layer  Sessions  -  to  promote,  discuss,  and 
defend  the  acceptance  of  KTP,  UMTP,  and/or  UDP  Into 
the  OSI  family  for  multicast  requirements  of  ISP. 

3.  Network  Layer  Sessions  -  to  promote,  discuss,  and 
defend  the  need  for  a  multicast  internet  to  support  the 
ISP. 

C.  Submit  the  ISP  through  PM  TRADE  to  JCS  far 
consideration  and  backing  as  the  OSI  Application  Layer 
standard  for  Simulators. 

0.  Coordinate  the  JCS  and  NIST/RNSI/ISO  efforts  to  a 
successful  conclusion.  Publish  the  ISP  standard. 
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111.  UIAN  CHARACTERISTICS  FOR  DISTRIBUTED  SIMULATORS 
ARCHITECTURE  [OSA]  APPLICATION 


PURPOSE:  To  dotermlne  the  WAN  characteristic*  of 
Import  for  BSR  applications. 


1.  Bandwidth  -  Tt  and  higher  for  short  duration  (weeks) 

training  exercises  [Exercises  planned  in 
advance]. 

-  9.6KBPS  to  56KBPS  for  continuous  operation 
[dependent  upon  needs!. 

2.  Minimum  cost  and  setup/teardown  time  for  the  short  term 
wide  band  support. 

3.  Guaranteed  level  of  service,  preferably  non-swltched 
during  exercises  (could  become  mandatory  for  secure 
operation). 

4.  LAN-WAN  gateways  at  the  LAN  sites,  not  at  the  Long  Haul 
Uendors  facilities. 

5.  COMSEC  facilities  at  the  LAN  sites. 

6.  Centrally  managed  with  distributed  submanagement 
functions. 

7.  Committed  to  OSI  for  COTS/NOI  cost  effective 
implementations. 

8.  Must  be  able  to  network  training  simulators  with  fielded 
and  future  battlefield  OPFRCs,  f  letforms,  and  Command 
Posts;  providing  these  simulators  with  their  required 
battlefield  C3l  information. 

9.  Must  support  a  comprehensive  security  policy  ond 
implementation. 


IU.  OPEN  SYSTEMS  INTERCONNECT  IOSI]  RRCHITECTURE 


Purpose:  To  provide  the  PM  TRROE  Distributed  Simulators 
uiith  a  communications  architecture  that  Is  supportable 
through  Commercial  iff  The  Shelf/  Nee-Developmental 
Item  ICOTS/NDI]  materiel;  and  to  provide  these 
distributed  simulators  with  the  ability  to  enchange  C3I 
Information  os  they  weald  In  a  battlefield  environment. 

The  network  concept  for  the  Distributed  Simulator  Architecture  iDSfil  Is  et 
enclosure  A.  The  DSR  protocol  profiles,  for  clarity,  ore  presented  In  segments 
under  the  some  enclosure. 

R.  SE6MENT  I  -  supporting  the  Interactive  Simulation  Protocol  IISP]. 

This  communications  protocol  profile  Is  the  pictorol  representation  of  the  DSR 
required  to  provide  service  to/for  the  ISP. 

B.  SEGMENT  II  -  supporting  the  C3I  communication  enchange  requirements. 
This  communications  protocol  profile  Is  the  pictorol  representation  of  the  DSR 
necessary  to  support  the  C3I  information  enchange  among  and  between  the 
distributed  simulators.  It  carries  60SIP,  DON,  and  tactical  communication 
profiles  which  provide  Interconnect  wlth/to  the  Rrmy  Common  Hardware  and 
Software  and  Maneuver  Control  Systems  as  well  os  RTRCS,  SINC6RRS,  MSE, 
EPLRS,  and  JTIDS  communications  systems.  This  softwore,  known  os  MCS 
Version  11.  written  in  RDR  for  the  it, 000  family  of  processors  running  under 
the  UNIH  operating  system  will  be  available,  for  free,  from  PM  OPTflDS  and  PEO 
CCS. 


C.  SEGMENT  III  -  supporting  the  real  tlmeTRBIL  traffic. 

This  communications  protocol  profile  Is  the  pictorol  representation  of  the  DSR 
required  for  possoge  of  real-time  track  data  to/omoag/botween  the 
distributed  simulators  by  their  supporting  and/or  supported  elements.  It  Is 
not  on  OSI  conforming  stack,  but  Is  Implemeatible  with  on  OSI  conforming  COTS 
lower  layer  profile  1 1  -41  directly  Interfaced  to  the  JCS  end  DoD  approved 
TRDILS.  This  non-conforming  profile  Is  necessary  to  provide  real  time  service 
to  the  Implementing  OPFRCS,  Platforms,  and  Command  Posts  until  the  TRDILS 
con  be  restructured  to  conform  with  the  OSI  architecture. 

0.  SEGMENT  IU  -  composite  DSR  (TB0|. 

This  Is  the  resultant  of  fl+B+C  obove.  Specific  Implementations  will  be  defined 
In  the  future  for  the  varrylng  simulator  configurations/interactions  and  for 
the  LRN/IVRN  gateways,  bridges,  ond  routers. 

E.  SE6MENT  U  -  supporting  security  functions  of  tbo  network  tTBDl. 

This  segment  shall  address  the  security  overtoy  to  tbo  BSR  for  eHchenge  of 
classified  Information.  Simulator  and  network  functional  Implementations 
will  be  addressed  os  well  os  the  netwnrt  management  interfaces. 
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IU.  OPEN  SYSTEMS  INTERCONNECT  [QSI]  ARCHITECTURE 

Icontl 


F.  SC6MENT  III  -  supporting  network  management  and  administration  [TBD]. 
This  segment  shall  address  the  network  management  and  administration 
functions  required  by  the  DSR,  including  the  the  Configuration  Management 
and  Hardware/Software  Support  requirements  of  both  the  simulators  and  the 
network. 
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Consolidated  output  of  the  working  group,  briefed  to  the  conference  at 
large,  consisted  of  general  statement s  of  intent  as  follows: 

0)  Hosting  Present  Standards  •  Recommend  the  embedding  of  DoD 

Standards  such  as  JCS  Pub  25  (USMTFs),  JCS  Pub  6  (TADlLs  AS.Ch  TADIL 
J  TIDP  Vols.  D  &  VI.  NATO  STANAGS.  Links  11  A  16.  etc.,  into  the  SIMNET 
Packet  Data  Unit  (PDU)  to  provide  the  Command  and  Control 
information  to  the  S/Ts. 

1)  Security  -  SIMNET  must  be  capable  of  networking  both  unclassified  and 
classified  environments  (up  to  secret). 

2)  Present  protocol  profile  implementation  -  This  task  requests  that  BB&N 
quantify  their  protocol  profile  in  OSI  parlance. 

3)  Time  Stamping/Latency  -  [SIMNET  requires  that  real-time  packets 
traversing  the  network  be  provided  a  mechanism  to  handle  the  packet 
latency  issue].  Determine  the  proper  approach,  taking  into  account 
both  information  and  hardware/software  available  from  the  Joint 
Interoperability  and  Evaluation  System  (JIES)  and  from  the 
Autonomous  Land  Vehicle  (ALV)  programs. 

4)  ISO-OSI  Profile  Recommendations  -  Define  and  determine  a  specific  set 
of  OSI  protocol  profiles,  (within  the  framework  of  GOSIP  Phase  I  and 
Phase  II,  and  compatible  with  the  NATO  OSI  transition  strategy  adopted 
by  member  nations),  to  be  implemented  by  all  SIMNET  operable 
products,  as  articulated  within  the  SIMNET  specification.  Includes 
evolution  to  FDDI  and  ISDN. 

5)  NIST,  ITS/NTIA,  and  University  Support  -  Define  the  support  roles  of  the 
above  institutions  and  academia  as  a  minimum. 

6)  Networking  Resources  •  Define  and  determine  the  cooperative 
opportunities  and  sharring  of  networking  resources  for  efficient  and 
effective  SIMNET  evolution.  Defines  interactions  in,  among,  and 
between  MILNET,  DSNET,  SCINET,  AIN,  JITS,  JIES,  CALS,  NATO  and 
services  such  as  FTS  2000. 
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PICTORflL  OF  DISTRIBUTED  SIMULATOR  ARCHITECTURE  NETWORK  CONCEPT 


ISSUES:  1.  USE  OF  FTAM  AMD  VTP  OVER  HALF-DUPLEX  SYSTEMS  ? 

2.  FURTHER  DEFINITION  OF  MSE  NETWORK  MANAGEMENT  SERVICE8 


1ST  UPDATE 

For  The  Communications 
Architecture  Subgroup 


Dr.  Henry  Williams 
University  of  Central  Florida 
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0072-1041 


ISODE  SYSTEM  ENVIRONMENT  (1ST) 


0072-1042 
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CONSTRUCTION  OF  OSI  STACK 
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Multi  -  Initiator/Responder  Processes 
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•  Define  Simulation  Specific  Services 

•  Include  Connectionless  Services 

•  Complete  OSI  stack  portability  by  developing 
protocol  stack 


CURRENT  STACK  ENVIRONMENT  (1ST) 
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Connection  -  Oriented  Services  (ACSE) 

Send  packets  across  Ethernet  between  any  two  of  three  machines 
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SUMMARY 
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Results  of  DARPA  WAREX  3/90 
and  BFIT  Exercises 
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WAREX  03/90  Army  Objectives 
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DARPA  Wideband  Network 
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WAREX  3/St‘  WAN  Gateway 
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WAREX  3/90  Demonstration 
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WAR  EX  3/90  Demonstration  (Cont.) 
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WAREX  3-90  SITE  CONFIGURATION 
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Navy  Battle  Force  Inport  Training  (BFIT)  -  DARPA  SIMNET 
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BFIT  SITE  CONFIGURATION 
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BF1T  /  SIMNET  Demonstration  Results 
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ISSUES  FROM  POSITION  PAPERS 


Note:  Due  to  time  limitations,  these  issues  were  not 
explicitly  discussed  in  the  meeting.  Some  of  these  issues  were 
covered  in  the  Required  Network  Services  discussion. 
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Communications  Architecture  Subgroup 
Questions  and  Issues 

1 .  Communication  Requirements: 

Communication  requirements  of  the 
DIS  application  should  be  specified 
(Network  management  functions 
should  also  be  specified).  Should 
these  requirements  be  specified  in  the 
current  standard?  If  so,  how  should 
they  be  timed? 

2.  PDU  Size: 

What  should  me  maximum  PDU  size 
be? 

3.  Site,  Host,  Identification: 

How  are  Identification  numbers  to  be 
assigned?  Are  they  permanently 
assigned  or  assigned  at  the  start  of 
each  exercise?  Who  assigns  the 
numbers? 
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4.  TADIL-J/JTIDS?Link-16: 

Should  these  models  be  adhered  to? 
How  do  these  models  affect  the 
current  standard?  Future  standard 
work? 


5.  Network  Traffic: 

What  kinds  of  recommendation  can  be 
made  to  reduce  the  number  of 
messages  that  need  to  be  issued  to 
accomplish  the  goals  of  DIS? 


6.  Priority  and  Security: 

Fields  representing  the  priority  and 
security  level  of  a  PDU  are  going  to  be 
added  to  the  PDU  header.  Does  the 
communications  architecture  group 
have  any  recommendations 
concerning  how  thv  should  be 
accomplished? 
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